| Package | hl7.ehrs.ehrsfmr21 |
| Type | Requirements |
| Id | Id |
| FHIR Version | R5 |
| Source | http://hl7.org/ehrs/https://build.fhir.org/ig/mvdzel/ehrsfm-fhir-r5/Requirements-EHRSFMR2.1-TI.1.5.html |
| Url | http://hl7.org/ehrs/Requirements/EHRSFMR2.1-TI.1.5 |
| Version | 2.1.0 |
| Status | active |
| Date | 2024-11-26T16:30:50+00:00 |
| Name | TI_1_5_Non_Repudiation |
| Title | TI.1.5 Non-Repudiation (Function) |
| Experimental | False |
| Realm | uv |
| Authority | hl7 |
| Description | Limit an EHR-S user's ability to deny (repudiate) data origination, transmission or receipt by that user. |
| Purpose | An EHR-S allows data entry to a patient's electronic health record and it can be a sender or receiver of healthcare information. Non-repudiation is a way to guarantee that the source of the data/record cannot later deny that fact; and that the sender of a message cannot later deny having sent the message; and that the recipient cannot deny having received the message. Components of non-repudiation can include: - Digital signature, which serves as a unique identifier for an individual (much like a written signature); - Confirmation service, which utilizes a message transfer agent to create a digital receipt (providing confirmation that a message was sent, and/or received); - Timestamp, which proves that a document existed at a certain date and time; - The use of standardized timekeeping protocols (e.g., the Integrating the Healthcare Enterprise (IHE) Consistent Time Profile). |
No resources found
No resources found
Note: links and images are rebased to the (stated) source
Limit an EHR-S user's ability to deny (repudiate) data origination, transmission or receipt by that user.
An EHR-S allows data entry to a patient's electronic health record and it can be a sender or receiver of healthcare information. Non-repudiation is a way to guarantee that the source of the data/record cannot later deny that fact; and that the sender of a message cannot later deny having sent the message; and that the recipient cannot deny having received the message. Components of non-repudiation can include:
| TI.1.5#01 | dependent SHALL |
The system SHALL capture the identity of the entity taking the action according to scope of practice, organizational policy, and/or jurisdictional law. |
| TI.1.5#02 | dependent SHALL |
The system SHALL capture time stamp of the initial entry, modification and exchange of data according to scope of practice, organizational policy, and/or jurisdictional law. |
| TI.1.5#03 | dependent SHALL |
The system SHALL conform to function [[TI.2]] (Audit) to prevent repudiation of data origination, transmission and receipt according to scope of practice, organizational policy, and/or jurisdictional law. |
| TI.1.5#04 | dependent SHOULD |
The system SHOULD conform to function [[RI.1.1.4]] (Attest Record Entry Content) to ensure integrity of data and data exchange and thus prevent repudiation of data origination, transmission or receipt according to scope of practice, organizational policy, and/or jurisdictional law. |
FHIR{
"resourceType" : "Requirements",
"id" : "EHRSFMR2.1-TI.1.5",
"meta" : {
"profile" : [
"http://hl7.org/ehrs/StructureDefinition/FMFunction"
]
},
"text" : {
"status" : "extensions",
"div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <span id=\"description\"><b>Statement <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b> <div><p>Limit an EHR-S user's ability to deny (repudiate) data origination, transmission or receipt by that user.</p>\n</div></span>\n\n \n <span id=\"purpose\"><b>Description <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Informative Content\" class=\"informative-flag\">I</a>:</b> <div><p>An EHR-S allows data entry to a patient's electronic health record and it can be a sender or receiver of healthcare information. Non-repudiation is a way to guarantee that the source of the data/record cannot later deny that fact; and that the sender of a message cannot later deny having sent the message; and that the recipient cannot deny having received the message. Components of non-repudiation can include:</p>\n<ul>\n<li>Digital signature, which serves as a unique identifier for an individual (much like a written signature);</li>\n<li>Confirmation service, which utilizes a message transfer agent to create a digital receipt (providing confirmation that a message was sent, and/or received);</li>\n<li>Timestamp, which proves that a document existed at a certain date and time;</li>\n<li>The use of standardized timekeeping protocols (e.g., the Integrating the Healthcare Enterprise (IHE) Consistent Time Profile).</li>\n</ul>\n</div></span>\n \n\n \n\n \n <span id=\"requirements\"><b>Criteria <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b></span>\n \n <table id=\"statements\" class=\"grid dict\">\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>TI.1.5#01</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n <i>dependent</i>\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL capture the identity of the entity taking the action according to scope of practice, organizational policy, and/or jurisdictional law.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>TI.1.5#02</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n <i>dependent</i>\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL capture time stamp of the initial entry, modification and exchange of data according to scope of practice, organizational policy, and/or jurisdictional law.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>TI.1.5#03</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n <i>dependent</i>\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL conform to function [[TI.2]] (Audit) to prevent repudiation of data origination, transmission and receipt according to scope of practice, organizational policy, and/or jurisdictional law.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>TI.1.5#04</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n <i>dependent</i>\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD conform to function [[RI.1.1.4]] (Attest Record Entry Content) to ensure integrity of data and data exchange and thus prevent repudiation of data origination, transmission or receipt according to scope of practice, organizational policy, and/or jurisdictional law.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n </table>\n</div>"
},
"url" : "http://hl7.org/ehrs/Requirements/EHRSFMR2.1-TI.1.5",
"version" : "2.1.0",
"name" : "TI_1_5_Non_Repudiation",
"title" : "TI.1.5 Non-Repudiation (Function)",
"status" : "active",
"date" : "2024-11-26T16:30:50+00:00",
"publisher" : "EHR WG",
"contact" : [
{
"telecom" : [
{
"system" : "url",
"value" : "http://www.hl7.org/Special/committees/ehr"
}
]
}
],
"description" : "Limit an EHR-S user's ability to deny (repudiate) data origination, transmission or receipt by that user.",
"jurisdiction" : [
{
"coding" : [
{
"system" : "http://unstats.un.org/unsd/methods/m49/m49.htm",
"code" : "001",
"display" : "World"
}
]
}
],
"purpose" : "An EHR-S allows data entry to a patient's electronic health record and it can be a sender or receiver of healthcare information. Non-repudiation is a way to guarantee that the source of the data/record cannot later deny that fact; and that the sender of a message cannot later deny having sent the message; and that the recipient cannot deny having received the message. Components of non-repudiation can include:\n- Digital signature, which serves as a unique identifier for an individual (much like a written signature);\n- Confirmation service, which utilizes a message transfer agent to create a digital receipt (providing confirmation that a message was sent, and/or received);\n- Timestamp, which proves that a document existed at a certain date and time;\n- The use of standardized timekeeping protocols (e.g., the Integrating the Healthcare Enterprise (IHE) Consistent Time Profile).",
"statement" : [
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : true
}
],
"key" : "EHRSFMR2.1-TI.1.5-01",
"label" : "TI.1.5#01",
"conformance" : [
"SHALL"
],
"conditionality" : false,
"requirement" : "The system SHALL capture the identity of the entity taking the action according to scope of practice, organizational policy, and/or jurisdictional law.",
"derivedFrom" : "EHR-S_FM_R1.1 IN.1.5#1"
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : true
}
],
"key" : "EHRSFMR2.1-TI.1.5-02",
"label" : "TI.1.5#02",
"conformance" : [
"SHALL"
],
"conditionality" : false,
"requirement" : "The system SHALL capture time stamp of the initial entry, modification and exchange of data according to scope of practice, organizational policy, and/or jurisdictional law.",
"derivedFrom" : "EHR-S_FM_R1.1 IN.1.5#2"
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : true
}
],
"key" : "EHRSFMR2.1-TI.1.5-03",
"label" : "TI.1.5#03",
"conformance" : [
"SHALL"
],
"conditionality" : false,
"requirement" : "The system SHALL conform to function [[TI.2]] (Audit) to prevent repudiation of data origination, transmission and receipt according to scope of practice, organizational policy, and/or jurisdictional law.",
"derivedFrom" : "EHR-S_FM_R1.1 IN.1.5#3"
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : true
}
],
"key" : "EHRSFMR2.1-TI.1.5-04",
"label" : "TI.1.5#04",
"conformance" : [
"SHOULD"
],
"conditionality" : false,
"requirement" : "The system SHOULD conform to function [[RI.1.1.4]] (Attest Record Entry Content) to ensure integrity of data and data exchange and thus prevent repudiation of data origination, transmission or receipt according to scope of practice, organizational policy, and/or jurisdictional law.",
"derivedFrom" : "EHR-S_FM_R1.1 IN.1.5#4"
}
]
}
XIG built as of ??metadata-date??. Found ??metadata-resources?? resources in ??metadata-packages?? packages.